Attention is first drawn to FIG. 1 showing a schematic illustration of a system 100 for accessing data in an external virtual memory, and also occasionally to FIG. 2 illustrating a host associated with a few volumes by means of corresponding ITLs, in accordance with the prior art. The system includes one or more hosts 101-1 to 101-n, hosting each of one or more applications (not shown) and coupled to a storage system 102 for accessing data residing in an external storage system. The data resides in volumes (denoted Vs, not shown in FIG. 1) of external virtual memory (say spread across virtual disk units 104-1 to 104-n). Note that Vs is storage system/vendor specific and in certain cases it is unanimous with Global Unit ID (GUID) or with a volume serial number.
An application (not shown) in Host 101-1 accesses a volume of external virtual memory 104-2 through a handle being for example ITL where I stands for initiator port, say 108-1 and T stands for a target port, say (109-2), and L stands for LUN, say 110-1. As is well known, the host may employ a plurality of initiator ports each of which is associated to one or more applications. The virtual memory may employ a plurality of target ports typically according to the number of volumes spread across the virtual memory where each pair of corresponding initiator port and target port is connected by means of unique Logical Unit Number—LUN. Thus, for example, initiator port 108-n and target port 109-(n−1) are connected through unique LUN (110 n−1). This can be illustrated, for example, also with reference to FIG. 2 where application 202-n of Host 101-2 accesses (through initiator port 108-1) any of volumes Vs1-Vs4 (201-1 to 201-4) of external virtual memory 104-2 through respective target ports 109-2 (A)-(D).
Note that whereas for convenience of explanation the link between the Initiator port and the Target port is marked by LUN, the latter is not a physical entity but rather it is a logical entity, e.g., an entry in a table that signifies that a connection from I to T is allowed and it is identified with that number. Note also that a plurality of LUNs may be associated with a given Target port.
The specified volumes may represent snapshots (each volume representing one or more snapshots) of data of a primary volume associated with the host. The snapshots are created in accordance with a pre-defined policy prescribed by the storage manager, e.g. 107 of FIG. 1).
Reverting now to FIG. 1, there are also shown host management modules 103-i each associated with its respective host 101-i operating under the control of Storage Administrator module 107 for providing handles viewed by the volumes and by the applications. As is well known, LUN is the identifier of a device which is being addressed by storage access protocol (e.g. SCSI protocol). As shown, for example, in FIG. 2, each of the specified volumes Vs1 to Vs4 (201-1 to 201-4) is accessible to the application APn by means of respective unique LUN 203-1 to 203-4. It is thus evident that for an application to access data (utilizing an access protocol command, say SCSI) in a volume of virtual memory, an ITL that associates the application and the volume, is utilized. In the latter, I stands for the initiator port (say 108-1 in FIG. 2), T stands for target port of the volume (say 109 (2) B, in FIG. 2) and L stands for the unique LUN. ITL is an example of a volume viewable handle. From the perspective of the host side, the volume is viewable to the application by associating the handle (e.g. ITL) to the application by an application viewable volume Vh allowing the application to access the associated volume. Note that the syntax of Vh is operating system specific. For MS windows operating systems for example, Vh is indicated by a label of the form X: where X can be any single alphabet letter. Note that whereas for convenience of explanation the application viewable volume is indicated on a seemingly physical connection linking the host to the volume (see “Drive a:” in FIG. 2), the application viewable volume is of course a logical entity allowing the application to access volume.
Reverting now to FIG. 1, whenever an application wants to address a given volume for accessing data, it must request the storage manager 107 to allocate an ITL for associating a given initiator port of the application in the host to a target port of the designated volume in the virtual external memory. The application will access the specified given volume by means of the application viewable volume Vh.
Bearing this in mind, attention is drawn to FIG. 3 showing a flow chart illustrating a sequence of ITL provisioning for accessing data in volumes of external virtual memory, in accordance with a prior art system.
Thus, in stage 301 a volume Vs is created on the external storage system. This operation is typically executed by a storage administrator (say 107 of FIG. 1) on the external storage.
Then in 302, an ITL (that was created by the storage administrator 107) is associated to the volume. This provisioning of ITL is typically executed by a storage administrator (107) and includes attaching the target port of the volume to the so generated LUN as well as attaching the LUN to the initiator port of the host. Note that the specified attachment typically involves human intervention (at storage administrator end) in order to permit the specified attachment of the LUN.
Then, in 303 the ITL is associated with Vh (application viewable volume) allowing the application to view the volume. This operation is typically executed at the host (e.g. automatically by the operating system or by the host manager such as 103-i associated with the respective host, see FIG. 1). As specified above, the host viewable volume Vh, is for instance, in the ease of MS operating system, indicated by a label of the form X: where X can be any single alphabet letter. At stage 304, Vh is associated to the application. This may be implemented by the host administrator (say 103-i of FIG. 2). The application on the host can now utilize Vh as a handle through which it can access data (e.g. read, write) on volume Vs. Normally, security rules are imposed by the storage manager for instance only if the volume Vs is a representative of a given snapshot of an application's primary volume of data, then the application can access the desired volume Vs (through the respective Vh) and read the snapshot data or write data thereto.
In should be noted that logical volumes may be created automatically e.g. in accordance with a policy prescribed by the storage manager, for instance in the case of volumes which hold snapshots. Note that, in particular, in cases where a very large number of snapshots is to be maintained, this may entail that a very large number of snapshots for a particular volume exist whereas the application normally accesses very few snapshots at a time (out of the large number of created snapshots).
Thus, for each created snapshot, the whole provisioning cycle discussed above is executed involving the storage manager (e.g. 107 of FIG. 1 including human intervention—as discussed above) obviously posing an undue overhead when the number of snapshots is large. This stems from the fact that storage resources and access to storage is typically managed by a storage administrator, while application access to storage is managed by a host administrator. Accordingly in many prior art systems, in the provisioning procedure, an automatic generation of snapshots may be inhibited and moreover, external storage has to maintain an unnecessarily large number of ITLs, since applications access very few (if at all) snapshots at a time. In addition, the host has to maintain an unnecessarily large number of Vh host viewable volumes which are generated in accordance with the created snapshots, notwithstanding the fact that the host accesses one or only a few (if any) concurrently.
It should be also noted that whilst the snapshots reside in volumes of external virtual memory such as 104-2 of FIG. 2, this has nothing to do with the actual storage of the data in physical storage. For a better understanding of the foregoing, attention is drawn to FIG. 4 which illustrates schematically, mapping between the virtual and physical storage according to the prior art. Thus, as shown, virtual storage system 41 includes volumes 42, 43 and 44 which are mapped to physical storage disks of physical storage system 45. Thus, in this example, the physical storage includes disks 46 to 49. As shown by way of example only data chunks 42a and 42b in volume 42 may be mapped through pointers 401 and 402 (of mapping scheme 400) to different physical locations (cluster 46a of physical disk 46 and cluster 47a of physical disk 47). Reverting to FIGS. 1 to 3 above, when an application accesses through a given LUN data item(s) in a volume of external virtual memory, the data actually resides in a physical storage that is transparent to the application. Any write operation to a volume representing a snapshot will be reflected in a known per se manner in the physical storage actually storing the snapshot data.
Prior art references considered to be relevant as a background to the presently disclosed subject matter are listed below. Acknowledgement of the references herein is not to be inferred as meaning that these are in any way relevant to the patentability of the presently disclosed subject matter disclosed herein:
WO 2010/085228 entitled “Method and System for Dynamic Storage Tiering Using Allocate-On-Write Snapshots” discloses a system and method for dynamic storage tiering including creating a point-in-time copy of a virtual volume including a storage hot-spot, copying a virtual volume segment including the hot-spot from a first storage pool to a second storage pool and reconfiguring a logical block address mapping of the virtual volume to reference the virtual volume segment copy in the second storage pool.
U.S. Pat. No. 7,275,103 entitled “Storage path optimization for SANs” discloses embodiments of a system and method for rule-based proactive storage path optimization for SANs. Embodiments may evaluate paths between an application and its storage on a SAN based on current and/or historical path quality of service. Performance of alternative paths may be monitored to determine if a better path than a path currently in use is available. If a better path is determined, then the path may be switched to the better path. In one embodiment, one or more zones may be reconfigured to migrate to a different path. Path migration may be performed automatically without user intervention. Alternatively, a user may be given the option to manually migrate to a new path. Embodiments may proactively change paths between an application and its storage before path performance becomes a problem. Embodiments may be integrated with a SAN management system or, alternatively, may be standalone mechanisms.
US 2004/0068636 entitled “Virtual storage systems, virtual storage methods and methods of over committing a virtual raid storage system” discloses virtual storage systems, virtual storage methods and methods of over committing a virtual RAID storage system. According to one aspect, a virtual storage system includes a virtual storage space, a physical storage space, a mapping system configured to associate a plurality of addresses of the virtual storage space with respective addresses of the physical storage space and a controller configured to automatically remove a portion of the mapping system according to a prioritization protocol which specifies removal of portions of the mapping system according to an order.
There is a need in the art for providing a new system and method for accessing data in an external virtual memory.